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(54) Information processing apparatus and method for executing software input from outside 



(57) An information processing apparatus tinat safe- 
ly executes unreliable software input from the outside is 
provided by the present invention. 

In the infonnation processing apparatus according 
to the present invention, a high level API judges whether 
or not an application that invol<ed the high level API has 
a certificate. If it has a certificate, the certificate that is 
included in a code is inspected. If the certificate is cor- 
rect, a low level API is invoked and a requested function 
is executed. If the application does not have a certificate 
or the certificate is not correct, security atthe time when 
the requested function is executed is evaluated. Wheth- 
er or not it is safe to execute the requested function is 
judged. If the function execution is judged to be safe, a 
low level API is invoked. If it is judged to be not safe, a 
low level API is not invoked and a message of an error 
is returned. 
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Description 

[0001] The present invention relates to an information 
processing apparatus and a method of processing in- 
formation in orderto more safely execute software input 
from the outside. 

[0002] Conventionally, there have been proposed in- 
formation processing apparatuses and systems for 
processing information in order to execute software 
which is not originally built in and is input from the out- 
side. If the software is input from the outside, its security 
will be questioned when executed. 
[0003] If malicious software is mistalonly executed, it 
can lead to the malfunction or demolition of equipment. 
There have been a variety of proposals for ways to en- 
sure the security of the software before it is executed. 
[0004] For example, in Japanese Patent Application 
Laid-Open No. 11-320287, whether or not executable 
data that has been downloaded is authenticated with a 
guarantee of a third party is judged. If it is not, its access 
to computer resources is prohibited. 
[0005] I n Japanese Patent Application Laid-Open No. 
2000-57045, authentication and authorization of a client 
are confimned with a certificate given to a client code 
module, and a permission object that enables a pemnit- 
ted method to be invoked is passed from a server to the 
client. 

[0006] I n Japanese Patent Application Laid-Open No. 
10-83310, as to authentication, a third party does the 
certifying. As to access control, an access control list 
distributed together with a program is inspected by a cli- 
ent system. 

[0007] However, it is desired that those conventional 
examples make further improvements in terms of the fol- 
lowing points: 

[0008] To authenticate a client, in conventional cases, 
a certificate is used. While using the certificate is a meth- 
od that provides high security, obtaining one requires 
costs as it has to be issued by a third party. Furthermore, 
security ensuring is left to the third party, and this does 
not always provide perfect security. 
[0009] If the authentication is done with a certificate, 
software that does not have a certificate is only given 
the minimum level of authorization. For example, soft- 
ware that is downloaded from the outside and does not 
have a certificate is not permitted to access a local file 
system. 

[0010] Contrarily, there have been conventionally pro- 
posed methods in which certificates are not used. How- 
ever, they apply authentication by password or encrypt- 
ed user IDs, which poses problems of lowered security 
and applications confined within the local. 
[0011] Accordingly, to address such problems, it is an 
object of the invention to provide an information 
processing apparatus, a method of processing informa- 
tion and a program that may safely execute unreliable 
software, for example a software input from the outside. 
[0012] It is another object of the invention to provide 



an information processing apparatus, a method of 
processing information and a program that may prevent 
the execution of malicious programs intended to cause 
the malfunction or demolition of equipment. 
5 [0013] It is yet another object of the invention to pro- 
vide an information processing apparatus, a method of 
processing information and a program that are capable 
of giving authorization for less-limited equipment control 
to software input from the outside. 
10 [0014] This invention provides an information 
processing apparatus for executing a requested func- 
tion in accordance wrth the execution of a program code. 
The apparatus comprises reliability judging means for 
judging the reliability of said program code, security 
'15 evaluating means for evaluating the security of said 
function requested by said program code, when said re- 
liability judging means judges said program code to be 
unreliable, and control means for executing said re- 
quested function, when said security evaluating means 
20 evaluates said requested function as being safe. 

[0015] Furthermore, this invention provides a method 
of processing information for executing a requested 
function in accordance with the execution of a program 
code. The method comprises the steps of, judging the 
25 reliability of said program code, evaluating the security 
of said function requested by said program code, when 
said program code is judged to be unreliable, and exe- 
cuting said requested function when said requested 
function is evaluated as being safe. 
30 [001 6] A number of embodiments of the invention will 
now be described, by way of example only, with refer- 
ence to the accompanying drawings in which: 
[0017] FIG. 1 is a block diagram showing a configu- 
ration of an information processing apparatus in an em- 
35 bodiment, 

[0018] FIG. 2 is a diagram showing an example of a 
software hierarchy of a client 101. 
[0019] FIG. 3 is a diagram showing another example 
of a software hierarchy of the client 1 01 . 
40 [0020] FIG. 4 is a flowchart showing an operation pro- 
cedure of a high level native API. 
[0021] FIG. 5 is a flowchart showing an operation pro- 
cedure of a high level API where a certificate is not in- 
spected. 

45 [0022] FIG. 6 is a flowchart showing an operation pro- 
cedure of a low level API. 

[0023] FIG . 7 is a flowchart showing an operation pro- 

cedure of a low level API. 

[0024] FIG. 8 is a flowchart showing an operation pro- 
50 cedure of an imaging API being a level API. 

[0025] FIG . 9 is a flowchart showing an operation pro- 
cedure of an imaging API that prevents imaging from 
being repeated at very short intervals. 
[0026] FIG. 10 is a flowchart showing an operation 
55 procedure of an e-mail transmitting API. 

[0027] FIG. 11 is a flowchart showing an operation 
procedure of a timer API. 

[0028] FIG. 12 is a flowchart showing an operation 
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procedure of a functional API where security evaluation 
and function execution are carried out by one API, 
[0029] One ennbodinnent of the invention will be de- 
scribed with reference to the drawings: 

FIG. 1 is a block diagrann showing a configuration 
of an infornnation processing apparatus in this enn- 
bodinnent. In the Figure, 1 01 indicates a client com- 
puter (simply referred to as a client). 
The client 101 comprises a CPU 106 for controlling 
operations of the entirety, a hard disl< (HD) 107, a 
RAIVI 108 for temporarily storing data and such, a 
ROM 109 for storing program codes (simply re- 
ferred to as codes) and such, a removable media 
drive 110 which storage media (removable media) 
for exchanging codes or data with outside are freely 
inserted in or removed from, a wireless communi- 
cation 111 for communicating with outside by radio, 
and an imaging apparatus 112. 

[0030] All the above devices are show an example of 
devices that would be included in the client 101 . Some 
of those can be omitted and other devices may be com- 
prised. 

[0031] In the Figure, 1 02 indicates a serverfor storing 

a code 103 that is input to and executed by the client 
101. The code 103 includes a certificate 104 that indi- 
cates the creator of the code. The certificate 104 is 
signed with a secret key owned by a third-party organi- 
zation. Those who try to authenticate the certificate 1 04 
can confirm the creator of the code by verifying the cer- 
tificate 1 04 with a public key of the above third-party or- 
ganization. This makes it possible to judge the security 
of the code. 

[0032] 1 05 indicates a network for connecting the cli- 
ent 1 01 with the server 1 02. The code 1 03 is sent from 
the server 1 02 to the client 1 01 through the network 1 05. 
The network 1 05 may be wired or wireless and may be 
any form, not to mention a LAN, a WAN, or the Internet. 
[0033] FortheclientlOl , means for inputting the code 
103 from the outside is not limited to the network 105. 
The code 103 may be stored in a storage medium (re- 
movable medium) and installed in the client 1 01 through 
the removable media drive 110, 

[0034] FIG. 2 is a diagram showing an example of a 
software hierarchy of the client 101 . 
[0035] In the Figure, 201 indicates hardware. 202 in- 
dicates an operating system (OS). 203 indicates a na- 
tive application programming interface (API) for execut- 
ing various functions of the client 1 01 and it is described 
in such a language as C/C++ language. 
[0036] 204 indicates a Java Virtual Machine (Java 
VM), and it can execute applications that are described 
in Java language. Java is a trademark of Sun Microsys- 
tems, Inc. in the United States and other countries. 205 
indicates a Java Middleware API, which is an API de- 
scribed in Java languagefor executing various functions 
of the client 1 01 . These APIs can be regarded as a kind 



of high level API and invoke a native API 203, which is 
a corresponding low level API for executing the same 
function. These low level APIs are described according 
to Java Native Interface (JNI, a protocol for invoking a 
5 function of the C/C++ language from the Java lan- 
guage). 206 indicates a Java application and 207 indi- 
cates a native application. 

[0037] FIG. 3 is a diagram showing another example 
of a software hierarchy of the client 101. 

10 [0038] In the Figure, 301 indicates hardware. 302 in- 
dicates an OS. 303 indicates a low level native API (sim- 
ply referred to as a low level API) and it is described in 
a language such as the C/C++ language. It executes 
various functions of the client 1 01 , 304 indicates a high 

15 level native API (simply referred to as a high level API) 
and it is also described in such a language as the C/C++ 
language. The high level native API 304 executes vari- 
ous functions of the client 101 by invoking the corre- 
sponding low level native API 303. 305 indicates a na- 

20 tive application. 

[0039] Operation of the client 101 having such a con- 
figuration will be described. 

[0040] FIG . 4 is a flowchart showing an operation pro- 
cedure of a high level native API . The high native API is 

25 invoked from an application (any of the Java application 
206, native application 207, native application 305). 
[0041] This application is stored in memories such as 
the RAM 108, ROM 109. Before being stored in the 
memory, the application may exist in the server 102 or 

30 nnay exist in the ROM 1 09 from the beginning. The CPU 
106 reads it and executes the procedure of FIG. 4. 
[0042] When a high level API is invoked from the ap- 
plication, first, the high level API judges whether or not 
the application which invoked the high level API has a 

35 certificate (step S401 ). The code 1 03 of the application 
being executed includes the certificate 104 that indi- 
cates the creator of the code. 

[0043] However, there is a case where it does not in- 
clude a certificate. For example, if the code creator is 

40 judgedto be reliable by an operation assuror of the client 
101 (manufacturer of the client 101 , for example), at- 
taching the certificate 1 04 has significance. But in a con- 
trary case, attaching the certificate 104 gives no signif- 
icance, and in some cases the certificate 1 04 is not at- 

45 tached even if the code 1 03 is created. When a method 
of creating an application that can be operated in the 
client 101 is open to the public, it often occurs that a 
general user creates a code. In such a case, the code 
creator does not necessarily attach a certificate which 

50 requires costs. 

[0044] On the other hand, the certificate 1 04 does not 
necessarily need to be attached to the code 1 03 that is 
written into the ROM 1 09 at the time of shipment of the 
client 101 . In this example, to obviously show that the 

55 code 103, which is stored in the ROM 109, is reliable, 
and that it is different in that respect from the code 1 03 
that does not have the certificate 1 04 attached, the cer- 
tificate 104 is attached. 
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[0045] If the application has a certificate in step S401 , 
the certificate 1 04 included in the code 1 03 is inspected 
(step S402). I n this inspection , the public key of the third- 
party is used. According to the result, whether or not the 
certificate 1 04 is correct is judged (step S403). If the cer- 
tificate 1 04 is correct, the client 1 01 deternnines whether 
or not to pemnit the code creator (application) indicated 
by the certificate 1 04 to execute a function that its high 
level API should execute (step S404). 
[0046] In this determination, a table (not shown) is 
used in which code creators and corresponding pernnit- 
ted functions are noted. The certificate 104 itself nnay 
have a list of pernnitted functions, API logic itself nnay 
have a step process to judge whether or not the code 
creator is OK. 

[0047] In the case where the application is permitted 
to execute the function in step S404, in order to pass 
information on what invokes a low level API (here, an 
identifier of the high level API) as parameters for invok- 
ing a low level API, parameters of a client invoking a low 
level API are calculated (step S41 1 ). The parameters of 
an invoking client may be the high level API identifier 
(name of the API , for example) itself. In this case, how- 
ever, as it is easy for other functions to pretend to be the 
high level API, here, the parameters are an identifier 
signed with the secret key of the high level API itself. 
Instead of the secret key, a common key only known to 
the high level API and the low level API may be used. 
[0048] After the parameters are set, a low level API is 
actually invoked (step S412), and the requested func- 
tion is executed. After this, the processing finishes. In 
order to pass information on what invokes a low level 
API to the low level API, other methods may be applied 
instead of passing parameters. Furthermore, parame- 
ters are not necessary when the low level API is able to 
know what invokes it by checking a call stack, which also 
makes the calculation of step S411 unnecessary. 
[0049] On the other hand, when the application in- 
voked in step S401 does not have a certificate, when 
the certificate is not correct in step S403, or when the 
function which the high level API should execute is not 
permitted to be executed in step S404, the invoked ap- 
plication is judged to be unreliable, or the function is 
judged to be impermissible when there is no condition. 
Therefore, much attention is needed when a low level 
API is invoked. In this case, security is evaluated when 
the requested function is executed (step S405). 
[0050] Whether or not it is safe to execute the function 
is judged (step 406). If it is judged to be safe to execute 
the function, parameters of a client invoking a low level 
API is calculated (step S408) similarly to the process of 
step S411 , and a low level API is invoked (step S409). 
And information for security evaluation is revised (step 
S410). Afterthis, the processing finishes. This informa- 
tion will be used to re-evaluate security in step 405 next 
time a high level API is invoked. 
[0051] On the other hand, if it is judged to be not safe 
in step S406, a low level API is not invoked, and a mes- 



sage of an error is returned (step S407), and the 
processing finishes. 

[0052] In this embodiment, information for security 
evaluation is revised in step S410. However, this proc- 

5 ess is not executed to continue to the process step of 
S412. This means that function limitation based on the 
security evaluation is effective only for unreliable appli- 
cations and not for reliable applications. In other words, 
for example, if an upper limit is put on the number of 

10 times that a particular function is executed and an un- 
reliable application is not permitted to execute function 
to exceed the upper limit, the number of executing times 
is increased in step S41 0 every time the function is ex- 
ecuted in step S409. 

15 [0053] In step S406, whether or not the number of ex- 
ecuting times exceeds the upper limit is judged. Accord- 
ing to the result of the judgment, whether or not to permit 
the function execution is determined. This determina- 
tion, however, has no influence on reliable applications. 

20 An application that is still reliable even if its number of 
executing times has exceeded the upper limit can exe- 
cute the function. 

[0054] Furthermore, although information for security 
evaluation is revised in step S410, this process is dis- 

25 pensable. There are some cases where, without infor- 
mation revising, it is possible to evaluate security next 
time a high level API is invoked. For example, it would 
be assumed that the client 1 01 is undertaking a multi- 
tasking operation and is performing important process- 
so ing in a certain task and does not want an unreliable 
application to execute a function which interferes with 
this processing. In such a case, security evaluation in 
step S405 may only judge whether or not the important 
processing is being done at present, and it is not nec- 

35 essary to revise information in step S41 0. 

[0055] Moreover, in the flowchart of FIG. 4, although 
the certificate is inspected when the high level API is 
executed, this is not an indispensable process, and the 
reliable application is provided to invoke a high level 

40 API. When the reliable application is supposed to invoke 
a low level API directly and only the unreliable applica- 
tion is supposed to invoke a high level API, certificate 
inspection and the procedure involved (step S401 to 
step S404) are not necessary. 

45 [0056] For example, the code 1 03 stored in the ROM 
109 is reliable and this invokes a low level API directly, 
and the code 103 downloaded from the server 102 is 
unreliable and this can not invoke a low level API directly 
and can only invoke a high level API. In this way, the 

50 high level API may always carry out security evaluation, 
and does not need to verify the code creator. 
[0057] Especially when the code 103 downloaded 
from the server 102 is described in Java language, it is 
normal to make the native API 203, which is a low level 

55 API, not to be directly invoked, and it is not necessary 
to specially add other means. The code 103 stored in 
the ROM 109 should be reliable, so that the certificate 
1 04 does not need to be attached. Furthermore, as it is 
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known to be safe to invoke a low level API, it is unnec- 
essary to set the parameters of an invoking client that 
is done in step S408. 

[0058] In the process shown in FIG. 4, the certificate 

is inspected so as to judge whether or not the application 
is reliable. As long as the application can be judged, oth- 
er methods may be applied instead of inspecting the cer- 
tificate. Such a method may be a unique method of a 
native system that can not be known to or used by the 
code 1 03 input from the outside. 
[0059] FIG. 5 is a flowchart showing an operation pro- 
cedure of a high level API where a certificate is not in- 
spected. In the Figure, the processes of steps S401 to 
S404 are replaced with a process of step S451. Other 
step processes (S452 to S459) are similar to the step 
processes of FIG. 4 (S405 to S412). 
[0060] In step S451 , whether or not the application 
that invoked a high level API is input from the outside of 
the client 101 is judged. Concretely, one example of a 
method would be as follows: if an address where an ap- 
plication exists is in the ROM 109, the application is 
judged to exist inside from the beginning, and if the ad- 
dress is in the RAM 1 08, the application is judged to be 
input from the outside. This method is applicable in the 
case where the application that exists inside is always 
executed from the ROM 109 and the application input 
from the outside is always placed in the RAM 1 08 to be 
executed from there. 

[0061] Another method would be as follows: flags are 
provided in each application. For an application input 
from the outside, the flag is turned ON when the appli- 
cation is input into the client 101 from the outside. For 
the application that exists inside from the beginning, the 
flag is turned OFF. By checking the flags, whether or not 
the application is input from the outside is judged. Here, 
it is not necessary to ask for a concrete method. 
[0062] To know whether or not an application is relia- 
ble in a simpler way, whether or not an application that 
invoked a high level API is a Java application may be 
judged. In this case, it is assumed that all the applica- 
tions that are input from the outside are Java applica- 
tions. Java applications rely less upon a system and are 
easy to be downloaded from the outside to be executed 
and thus are suitable as a described languagefor appli- 
cations input from the outside. 

[0063] If a high level API is part of the Java Middle- 
ware API 205, it is guaranteed that the application is a 
Java application 206 as long as the Java Middleware 
API 205 is not permitted to be invoked from the native 
API 203. In this case, therefore, it is possible to judge 
whether or not an application is reliable even without 
providing a step process to judge whether or not the ap- 
plication is a Java application. 

[0064] FIG. 6 is a flowchart showing an operation pro- 
cedure of a low level API. As shown in FIG. 4, a low level 
API is invoked from a high level API. First, the client 
checks what invokes the low level API (step S501). As 
has been shown in FIG. 4, when the invoking client is 



passed as parameters, the parameters are checked. If 
it is signed with a secret key or a common key, the key 
is verified to authenticate the invoking client. Or, if pos- 
sible, a call stack is examined to check the invoking cli- 

5 ent. 

[0065] According to the result of checking in step 
S501 , whether or not the low level API is invoked by the 
corresponding high level API is judged (step S502). If it 
is the high level API, the function provided by the low 
10 level API is executed (step S503). On the other hand, if 
it is not the high level API that invoked the low level API, 
a message of an error is returned (step S504). Afterthis, 
the processing finishes. 

[0066] If the low level API is only invoked from a reli- 
^5 able application or only invoked in a safe way, the steps 
S501 and S502 are unnecessary and simply the func- 
tion in step S503 may be executed. 
[0067] However, if there is not such limitation in invok- 
ing the low level API, that is, if there is a possibility that 
20 the low level API is invoked from an unreliable applica- 
tion, which has to be rejected by a sequence in the low 
level API, it could be requested that the low level API 
can be invoked without setting information on the invok- 
ing client in a reliable application. 
25 [0068] Operation processing of a low level API that 
satisfies this condition will be described. 
[0069] FIG . 7 is a flowchart showing an operation pro- 
cedure of a low level API. In the Figure, after a low level 
API is invoked not only from a high level API but also 
30 from any function or method, the low level API first judg- 
es whether or not the code 103 of an application that 
invoked the low level API has a certificate (step S601). 
[0070] If the code 1 03 has a certificate, the certificate 
104 included in the code 103 is inspected (step S602). 
35 In this inspection, as already described, the certificate 
1 04 is verified with the public key of the third-party or- 
ganization. According to the result, whether or not the 
certificate 104 is correct is judged (step S603). 
[0071] If the certificate 1 04 is correct, whether or not 
40 to permit the code creator indicated by the certificate 
104 to execute the function that the low level API should 
execute is judged (step S604). In this judgment, a table 
(not shown) is used in which code creators and corre- 
sponding permitted functions are noted. Or, the certifi- 
es cate 104 itself may have a list of permitted functions. 
Furthermore, API logic itself may have a step process 
to judge whether or not the code creator is OK. And if 
the function execution is permitted, the function provid- 
ed by the low level API is executed (step S607). 
50 [0072] On the other hand, when the application does 
not have a certificate in step S601 , when the certificate 
is not correct in step S603, or when the function that the 
low level API should execute is not permitted to be ex- 
ecuted in step S604, what invokes this API is checked 
55 (step S605). 

[0073] As has been shown in FIG. 4, when the invok- 
ing client is passed as parameters, the parameters are 
checked. If it is signed with a secret key or a common 
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key, the key is verified to authenticate the invoking client. 
Or, if possible, a call stack is examined to check the in- 
voking client. 

[0074] According to the result of the checking, wheth- 
er or not the low level API is invoked by the correspond- 
ing high level API is judged (step S606). If it is the high 
level API, the function provided by the low level API is 
executed (step S607). On the other hand, if it is not the 
high level API that invoked the low level API, a message 
of an error is returned (step S608). After this, the 
processing finishes. 

[0075] In the processes shown in FIG. 7, the applica- 
tion has the certificate 104. When function execution is 
permitted, the function of the low level API can be exe- 
cuted and it is not necessary to set information on an 
invoking client. This enables the low level API to be in- 
voked not just from the high level API shown in FIG. 4. 
[0076] It will be unnecessary to set information on an 
invoking client as shown in step S411 of FIG. 4. Natu- 
rally, in the case where a low level API is able to know 
the invoking client such as by examining the call stack, 
it is not necessary from the beginning to set the infor- 
mation on the invoking client, as already described. 
Nevertheless, as it is difficult for a low level API to know 
all that is permitted as invoking clients, it still has signif- 
icance in this processing where the low level API can 
be invoked from the high level API. 
[0077] Furthermore, in the process shown in FIG. 7, 
the certificate is inspected to judge whether or not the 
application is reliable. As long as the application can be 
judged, other methods may be applied instead of veri- 
fying the certificate. Such a method may be a unique 
method of a native system that can not be known to the 
code 1 03 input from the outside. 
[0078] As described, in the process shown in FIG. 4, 
security evaluation when the requested function is exe- 
cuted in step S405 has been shown. 
[0079] Next, how the security evaluation is actually 
carried out will be described according to a concrete ex- 
ample. 

[0080] FIG. 8 is a flowchart showing an operation pro- 
cedure of an imaging API being a high level API. The 
client 101 has, as described, an imaging apparatus 112 
with which imaging can be done. During imaging oper- 
ation, mechanical parts such as a shutter are driven, so 
that too hard action may cause damage to equipment. 
Malicious software for such purpose must be prevented. 
Therefore, a case will be described where the number 
of imaging times is counted after an electric source is 
turned ON, andthe upper limit on the number of imaging 
times is set for the execution from an unreliable appli- 
cation. 

[0081] In the Figure, steps S701 to S704, steps S706 
to S708, step S710 and step S711 , correspond to steps 
S401 to S404, steps S407 to S409, step S411 and step 
S412 in FIG. 4 respectively. A description of these is 
omitted. 

[0082] If an application is unreliable for such a reason 



as it does not have a certificate, whether or not the 
number of an imaging time counter exceeds the upper 
limit is judged (step S705). Here, the imaging time coun- 
ter is initialized to a value 0 at the time when the electric 
5 source of the client 1 01 is turned ON. If it exceeds the 
upper limit, a message of an error is returned (step 
S706). 

[0083] If the imaging time counter does not exceed 
the upper limit, processes after step S707 are executed, 
and an actual imaging function is executed by invoking 
a corresponding low level API. After this, the number of 
the imaging time counter is increased (step S709). 
Then, the processing finishes. 

[0084] To prevent the imaging apparatus 11 2 from be- 
ing damaged, it is necessary to prevent imaging from 
being repeated at very short intervals, in addition to lim- 
iting the number of imaging times. FIG. 9 is a flowchart 
showing an operation procedure of an imaging API that 
prevents imaging from being repeated at very short in- 
tervals. Processes of FIG. 9 are almost the same as 
those of FIG. 8. Except for processes of step S805 cor- 
responding to step S705 and except for step S809 cor- 
responding to step S709, the rest of the step processes 
are the same. Therefore, a description of the same step 
processes is omitted. 

[0085] In the Figure, if an application is unreliable for 
such a reason as it does not have a certificate, whether 
or not the elapse of time from the previous imaging time 
exceeds the minimum elapse of time is judged (step 
S805). If it does not exceed, a message of an error is 
retuned (step S806), 

[0086] On the other hand, if it exceeds, processes af- 
ter step S807are executed, and actual imaging function 
is executed by invoking a corresponding low level API. 
After that, imaging time is revised (step S809). That is, 
the present time is stored as a value of imaging time. 
This is done to prepare for the next time when the proc- 
ess of the S805 is executed. 

[0087] To prevent the imaging apparatus 112from be- 
ing damaged, it will be more effective to combine the 
processing of FIG. 8 and FIG. 9. For example, by storing 
the imaging time and the number of imaging times, it will 
be possible to provide restrictions that prohibit imaging 
from being done one hundred times or more within one 
minute. 

[0088] This serves to improved security in other as- 
pects as well as the prevention of damage caused to the 
imaging apparatus 112. For example, the number of 
transmitted e-mail may be given the upper limit so that 
the client 101 would not be used as a means of trans- 
mitting a large amount of e-mail such as spam mail. 
[0089] FIG. 10 is a flowchart showing an operation 
procedure of an e-mail transmitting API. Processes of 
FIG. 1 0 are almost the same as those of FIG. 8. Except 
for processes in step S905 corresponding to step S705 
and except for step S909 corresponding to step S709, 
the rest of the step processes are the same. Therefore, 
a description of the same step processes is omitted. 
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[0090] In the Figure, if an application is unreliable for 
a reason as it does not have a certificate, whether or not 
the number of transnnitted e-mail exceeds the upper limit 
is judged (step S905). If it exceeds, a message of an 
error is retuned (step S906). 

[0091] On the other hand, if it does not exceed the 
upper limit, processes after step S907 are executed, 
and an actual e-mail transmitting function is executed 
by invoking a corresponding low level API. After this, the 
number of transmitted e-mail is increased (step S909). 
Then, the processing finishes. 

[0092] Next, processing for setting the upper limit of 

communication time will be shown, which is slightly dif- 
ferent from the above-described processing of the high 
level API. FIG. 11 is a flowchart showing an operation 
procedure of a timer API. This processing prevents an 
unreliable application from communicating by means of 
the wireless communication 111 for a long time. 
[0093] When a timer API that measures time is in- 
voked from the OS 202, the timer API first judges wheth- 
er or not the wireless communication 111 is communi- 
cating (step SI 001). If it is communicating, whether or 
not the elapse of communication time exceeds the up- 
per limit is judged (step SI 002). If it exceeds the upper 
limit, processes of steps S1003 to S1006 are done as 
in steps S401 to S404 of FIG. 4. And whether or not the 
application using the wireless communication 111 is re- 
liable and whether or notthe communication can be con- 
tinued are judged (step S1 006). If the application is not 
reliable or the continuation of communication is not per- 
mitted, the communication is cut off (step S1 007). After 
this, the processing finishes. 

[0094] So far, concrete examples of security evalua- 
tion have been shown. However, the present invention 
is not limited to these examples in terms of preventing 
the malfunction and demolition of the client 1 01 and the 
reinforcement of security, and is applicable to various 
cases. 

[0095] In the above embodiment, a method is shown 
in which the execution of the function is separated into 
two layers; the high level API and the low level API. This 
enables a reliable application to invoke a low level API 
directly, so that rapid operation is expected. However, 
the present invention is not limited to this method. 
[0096] FIG. 12 is a flowchart showing an operation 
procedure of a function API where security evaluation 
and function execution are carried out by one API. 
[0097] In the Figure, processes of steps SI 201 to 
SI 207 correspond to those of steps S401 to S407 of 
FIG. 4. In the process of step SI 204, if an application 
that invoked the function API is permitted to execute the 
requested function, it simply executes the function (step 
SI 210). And if the application is judged to be safe to 
execute the function in step SI 206, it executes the func- 
tion (step SI 208). After that, information for security 
evaluation is revised (step SI 209). In this way, these 
processes are handled by one API. 
[0098] Furthermore, although this invention needs 



hardware, it can be implemented with programs that op- 
erate in each apparatus. Therefore, if a storage medium 
stores a program code of software that implement the 
function described In the embodiment, the function can 
5 be implemented by reading and executing the program 
code from the storage media. 

[0099] As described according to the present inven- 
tion, when a code is judged to be safe even though it is 
unreliable, it can execute the function. It Is thus possible 
10 to safely execute unreliable software that is input from 
the outside. 

[0100] This can prevent the execution of malicious 

programs that intend to cause the malfunction and dem- 
olition of equipment. This also gives software input from 
15 the outside authorization for less-limited equipment con- 
trol. 

[0101] According to the present invention, while an 
unreliable code is being executed, if a second control 
means is first booted, a first control means executes the 

20 function so that the unreliable code would not directly 
boot the first control means and execute a function. This 
not only enhances security but also enables the function 
to be executed more rapidly and efficiently because a 
reliable code can directly boot the first control means 

25 not via the second control means. 

[0102] Furthermore, according to the present inven- 
tion, when the first control means is booted, the second 
control means revises information that is used by a se- 
curity evaluating means for security evaluation, so that 

30 function limitation based on the security evaluation can 
be achieved in various forms. It is possible to make the 
function limitation effective only for an unreliable code 
and not for a reliable code. 



1 . An infonnation processing apparatus for executing 
a requested function in accordance with the execu- 
te tion of a program code, comprising: 

reliability judging means forjudging the reliabil- 
ity of said program code; 
security evaluating means for evaluating the 
45 security of said function requested by said pro- 

gram code, when said reliability judging means 
judges said program code to be unreliable; and 
control means for executing said requested 
function, when said security evaluating means 
50 evaluates said requested function as being 

safe. 

2. An information processing apparatus according to 
claim 1 , wherein said control means comprises first 

55 control means for executing said requested func- 
tion, and second control means for booting said first 
control means; and 
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said first control means executes said request- 
ed function, if said first control means is booted 
from said second control means wlien said un- 
reliable program code is executed. 

3. An information processing apparatus according to 
claim 2, wherein if said first control means is booted 
from said second control means when said unreli- 
able program code is executed, said first control 
means executes said requested function; and said 
second control means revises said information 
used for evaluating security by said security evalu- 
ating means when said first control means is boot- 
ed, 

4. An information processing apparatus according to 
claim 1 , wherein said reliability judging means judg- 
es on the basis of whether or not there is a certificate 
indicating a creator of said program code and 
whether or not the execution of said requested func- 
tion is permitted by said creator. 

5. An information processing apparatus according to 
claim 1 , wherein said reliability judging means judg- 
es said program code to be unreliable if said pro- 
gram code is input from the outside. 

6. An information processing apparatus according to 
claim 5, wherein said reliability judging means judg- 
es said program code to be unreliable if said pro- 
gram code is described in Java language. 

7. A method of processing information for executing a 
requested function in accordance with the execu- 
tion of a program code, comprising the steps of: 

judging the reliability of said program code; 
eval uati ng the secu rity of said f u notion req uest- 
ed by said program code, when said program 
code is judged to be unreliable; and 
executing said requested function when said 
requested function is evaluated as being safe. 

8. A method of processing information according to 
claim 7, wherein said step of executing said re- 
quested function comprises a first control step of ex- 
ecuting said requested function, and a second con- 
trol step of booting said first control step; and 

if said first control step is booted from said sec- 
ond control step when said unreliable program 
code is executed, said requested function is ex- 
ecuted in said first control step. 

9. A method of processing information according to 
claim 8, wherein if said first control step is booted 

from said second control step when said unreliable 
program code is executed, said requested function 



is executed in said first control step; and in said sec- 
ond control step, said information for evaluating se- 
curity is revised when said first control step is boot- 
ed. 

5 

10. A method of processing information according to 
claim 7, wherein in said step of judging reliability, a 
judgment is made on the basis of whether or not 
there is a certificate indicating a creator of said pro- 

10 gram code and whether or not the execution of said 
requested function is permitted by said creator. 

11. A method of processing information according to 
claim 7, wherein in said step of judging reliability, 

15 said program code is judged to be unreliable if said 
program code is input from the outside. 

12. A method of processing information according to 
claim 11, wherein in said step of judging reliability, 

20 said program code is judged to be unreliable if said 
program code is described in Java language. 

13. A storage medium for storing a program for execut- 
ing a requested function in accordance with execu- 

25 tion of a program code, said program comprising 
the steps of: 

judging the reliability of said program code; 
evaluating the security of said function request- 
so ed by said program code, when said program 
code is judged to be unreliable; and 
executing said requested function when said 
requested function is evaluated as being safe. 

35 14. A storage medium according to claim 13, wherein 
said step of executing said requested function com- 
prises a first control step of executing said request- 
ed function, and a second control step of booting 
said first control step; and 

40 

if said first control step is booted from said sec- 
ond control step when said unreliable program 
code is executed, said requested function is ex- 
ecuted in said first control step. 

45 

15. A storage medium according to claim 14, wherein 

if said first control step is booted from said second 
control step when said unreliable program code is 
executed, said requested function is executed in 
50 said first control step, and in said second control 
step said information for evaluating security is re- 
vised when said first control step is booted. 

16. A storage medium according to claim 13, wherein 
55 in said step of judging reliability, a judgment is made 

on the basis of whether or not there is a certificate 
indicating a creator of said program code and 
whether or not the execution of said requested func- 
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tion is permitted by said creator. 

7. A storage medium according to claim 13, wherein 
in said step of judging reliability, said program code 

is judged to be unreliable if said program code is 5 
input from the outside. 

8. A storage medium according to claim 17, wherein 
in said step of judging reliability, said program code 

is judged to be unreliable if said program code is io 
described in Java language. 
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FIG. 7 
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FIG. 12 
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